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ABSTRACT 

Studies at ESOC have demonstrated the feasibility 
of a flexible and powerful Engineering Database 
Management System in support for spacecraft 
operations documentation. 

The objectives set out were three-fold: first an 
analysis of the problems encountered by the 
Operations team in obtaining and managing 
operations documents; secondly, the definition of a 
concept for operations documentation and the 
implementation of prototype to prove the feasibility 
of the concept; and thirdly, definition of standards 
and protocols required for the exchange of data 
between the top-level partners in a satellite project. 

The EDMS prototype was populated with ERS-1 
satellite design data and has been used by the 
operations team at ESOC to gather operational 
experience. 

An operational EDMS would be implemented at the 
satellite prime contractor's site as a common 
database for all technical information surrounding a 
project and would be accessible by the co- 
contractor's and ESA teams. 
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1. BACKGROUND 

During the design of a satellite and after its 
manufacturing, a large amount of information has to 
be transferred from die prime contractor to the 
European Space Agency (ESA). The most important 
document is the Flight Operations Manual (FOM). 


Also, to respond to the needs of Operations and 
Assembly, Integration and Validation (AIV), ad-hoc 
documentation has to be produced. 

All this documentation is delivered in a paper-based 
form. Thus, once this documentation is received by 
the operations teams, the information contained 
therein needs to be retyped to produce e.g. the Flight 
Operations Plan (FOP) - the document which 
contains all the nominal and contingency flight 
procedures for a space mission. 

This effort requires enormous manpower from the 
operations teams. Also, production of operations 
documentation by spacecraft contractors historically 
receives a lower priority. 

2. PROBLEM 

The first consequence of this situation is that FOM's 
- these are produced by spacecraft sub-system - 
arrive late e.g. after the launch of the spacecraft. 

Furthermore, due to the intrinsic complexity of 
current generation spacecraft systems, problems 
arise in the overall management of the 
documentation. Thus, the spacecraft documentation 
will contain incoherent information. Also, the lack 
of management in spacecraft design changes has 
impacts on mission control. 

The nature of the documentation delivery - paper - 
generates huge distribution costs e.g. copying, 
mailing. 

Finally, because the documentation is not stored in a 
single repository, there is no complete access to 
information. 
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3. ANALYSIS 


One can identify a potential risk of mission failure 
(or at least a risk of reduced mission capability) 
from the above problems. Hence, the requirement to 
analyse the operations documentation production 
and review cycle within a spacecraft mission. 

Analysis of the ERS-1 mission (as a case study of a 
typical current generation mission) has revealed 
several shortcomings in all of the aspects of 
operations related documentation: generation, 
distribution, maintenance, review and archiving. The 
analysis included the working procedures of prime 
and co-contractors as well as the operations and 
spacecraft check-out teams. 

The main shortcoming identified was the lack of a 
single (and complete) repository for all operations 
documentation for a space mission. A concept for an 
Engineering Database Management System (EDMS) 
for spacecraft operations was thus developed. 

4. DEFINITION OF EDMS CONCEPT 


A set of constraints - technical and operational - 
dictated the main aspects of the EDMS concept. 

4.1.1. Distributed architecture 

Due to the distributed nature of spacecraft and 
mission development it is essential that each partner 
(prime, co-contractor, operations, etc..) in a 
spacecraft project can work independently on their 
own documentation and yet still have access to a 
common repository of information. A network of 
UNIX workstations and servers would satisfy this 
constraint. 

4.1.2. Open systems 

Because of the large number of partners involved, 
one must build an EDMS on open systems. This 
includes both hardware and software solutions. 
Software solutions must place the emphasis on 
neutral formats and standards for data exchange (e.g. 
SGML for text) and less on selection of specific 
software packages. 
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Since a spacecraft project involves a large number 
of partners, typically spread-out over several 
countries, an efficient means of distributing large 
volumes of documentation is needed. A Wide Area 
Network (WAN) based on standard communications 
protocol would meet this requirement 

4.1.4. Operations-friendly environment 

Use of an EDMS and production of operations 
documentation must follow closely procedures used 
in current paper-based space missions e.g. document 
review cycles, production of Review Item 
Discrepancies (RID's), Non-Compliance Reports 
(NCR’s), etc.. 

Furthermore, the types of current documentation 
must be maintained e.g. User Requirements 
Documents (URD’s), System Requirements 
Documents (SRD’s), Interface Control Documents 
(ICD’s), FOM's, etc.. 

4.2. Functionality 

Functional requirements for the EDMS generated 
from the above problem analysis and constraints. 

4.2.1. Desktop publishing 

Requirements here call for non-destructive editing 
(annotations), multi-author access, hyper-media 
functions, version and configuration control. 

4.2.2. Communications 

Identified requirements include E-mail, 
dissemination of documentation, delivery 
acknowledgement, access and security. 

4.2.3. Data archiving and retrieval 

Main requirements defined include adoption of 
unified data model and neutral data format for 
information storage and exchange, document 
browsing and navigation, text and concept retrieval. 

4.3. Responsibilities 

The mission prime contractor is seen as the key role 
player in any implementation of an EDMS. The 
prime contractor will be responsible for the 
gathering, maintenance and distribution of 
documentation from a Central Database (CDB). 


Co-contractors, ESA Project Offices, mission 
operations and check-out teams would maintain 
their own Local Database (LDB) which could 
contain an up-to-date version of the CDB as well as 
their own ’working’ copy. 

4.4. Usage Scenarios 

Usage scenarios would map the procedures from 
conventional project review cycles e.g. Baseline 
Design Reviews (BDR's), System Requirement 
Reviews (SRR's), FOM reviews, etc.. Additionally, 
the format and structure of project documents would 
be maintained in support of these formal reviews. 

5. IMPACT ON OPERATIONS 

The foreseen implementation of an operational 
EDMS will have several positive impacts on 
spacecraft missions: 

• Increased productivity - within ESA as well as 
the contractors 

• Improved communication of information 

• Reuse of information 

• Reliability and manageability of information 

In addition to the improved productivity within the 
operations teams in preparing documentation, it is 
anticipated that there will be a minimisation of 
response time in the case of a spacecraft anomaly. 

6. PROTOTYPE IMPLEMENTATION 

A prototype was implemented, containing the main 
functions of an operational EDMS, in order to 
demonstrate the feasibility of the concept described 
above. 

The main elements of the prototype included: 

• Sun workstations 

• Commercial-Off-The-Shelf (COTS) S/W 
packages: 

• DTP tool, Frame maker 

» RDMS tool, Oracle 

• Information retrieval tool. Topic 

• DB front-end/MMI tool, CIM-Linc ID 
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X. 400 messaging system, BIM-Mail 


They must also be able to accommodate the various 
constraints pertaining to specific aerospace domain 


{1 ): ID «-» FrameMaker 
bidirectional 
communication WF; 

(2) : Topic -> FrameMaker 

unidirectional 
communication l/F; 

(3) : BiMail -» FrameMaker 

unidirectional 
communication UF 


GLOBAL HCI 



Fig. 2: Software architecture of EDMS prototype 


The prototype was populated with data from ERS-1 
platform and the IDHT instrument. A review 
scenario was developed for the IDHT FOM life- 
cycle. 

7. PROTOTYPE DEMONSTRATION 

The prototype was demonstrated at ESOC in 
February 1992. The demonstration consisted of two 
workstations at ESOC, Germany - acting as the 
operations team - linked to one workstation based at 
Everberg, Belgium - acting as the prime contractor. 
The link was provided by ESA’s X. 25 network, 
ESANET. 

The prototype has since then been delivered to 
ESOC where it has been evaluated by the operations 
team. 

8. STANDARDS 

The adoption and use of neutral standards for the 
representation and the exchange of design 
knowledge is a key factor for the successful 
deployment of EDMS in real space projects. These 
standards have to rely on existing international 
recommendations when available and applicable. 


in terms of accuracy, flexibility and confidentiality. 

Current study effort has already identified Standard 
General Mark-up Language (SGML) as a potential 
standard for text exchange. Above and beyond this, 
the adequate definition of related Document Type 
Definitions (DTD's) is required - to ensure 
information completeness - for all documentation 
generated during a space mission life-cycle. 

9. CONCLUSIONS 

The feasibility of an operational EDMS has been 
proven through the implementation and 
demonstration of the prototype. 

The prototype demonstration received a positive 
response from major potential users of an EDMS: 
prime contractor, operations and check-out teams. 

There is a strong interest from spacecraft prime 
contractors to get involved in a pilot implementation 
of an EDMS within in a real space project. 
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